-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace pkg-config with pkgconf when the distribution is brew #26891
Conversation
installs pkgconf. Accordingly, this PR adjusts the expectations of `conf-pkg-config` to depend on `pkgconf`.
…om:emjin/opam-repository into pkgconf
Signed-off-by: Marcello Seri <[email protected]>
This was already tested |
First of all, thanks for your work on the opam-repository maintenance :) Hmm, I'd have expected to bump conf-pkg-config in the version number... now it is unclear when someone reports a failure in conf-pkg-config.3 what their brew depext candidate is/was. Furthermore, from my brief understanding, a recompilation for everybody using conf-pkg-config could have been avoided by bumping the version number (conf-pkg-config.3.1) and mark that as But I may be wrong, I'm a bit unhappy about unversioned conf-* package upgrades in general (adding distributions is usually not an issue, but modifying existing filters etc. is dangerous - I remember some breakage in the past), but if this is considered to be a good idea, please go ahead. |
You are right, of course.
The reason I decided not to bump the version in this case, is that almost every macOS user that uses homebrew uses the head of their packages branch. For all the others, who would see a failure with the new release, pending to 3.1 or to 2 would give the exact same package.
So I thought maybe this is one of those points in which we can avoid creating a new package since version 2 would be exactly equivalent for those user to version 2. With metadata changes if this type this is something we have done other times.
But I agree, maybe we should’ve just done a new version to avoid any confusion.
|
I thought with recent opams this should not happen unless you are on the system that was affected by the change. But I am absolutely not sure about it 😅 |
This seems to have broken our CI and the fix I found looks a bit strange https://github.com/coq/coq/pull/19836/files |
I'm seeing failure that look related to this. https://github.com/ocsigen/js_of_ocaml/actions/runs/11914383047/job/33202182023 |
The github runners have There are two options that I have seen working so far:
I am going to suggest an updated EDIT: updated with @hhugo workaround |
I suggested a new release, but it will not completely solve the problem. The runners are using an outdated package that conflicts with the new one and it seems that they have an issue with the symlink created by the new package (it is not found by opam) |
I've fixed my issue with ocsigen/js_of_ocaml#1737 |
Import #26878 with only the latest pkg-config-file updated (in case there are users still using older copies of homebrew)